home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 1
/
Cream of the Crop 1.iso
/
MONITOR
/
ALCV14.ARJ
/
ALCHEMY.DOC
next >
Wrap
Text File
|
1991-03-20
|
88KB
|
2,264 lines
Image Alchemy
Version 1.4
March 18, 1991
User's Manual
TM
Image Alchemy was written by
Marcos H. Woehrmann
Allan N. Hessenflow
David Kettmann
Copyright (c) 1990-1991 by Handmade Software, Inc.
All Rights Reserved 15951 Los Gatos Blvd., Suite 7
Los Gatos, CA 95032
+1 408 356-4143 (Fax)
+1 408 358-1292 (Voice)
UUCP: hsi@netcom.COM
or: apple!netcom!hsi
Cserve: 71330,3136
Shareware Fundamentals and Specifics
We encourage you to freely copy and distribute the shareware
version of Image Alchemy provided that:
1. No fee beyond normal media, duplication, and shipping
costs may be charged.
2. Shareware vendors and computer user groups who charge
less than $7.00 per disk may distribute Image Alchemy,
but Handmade Software must be supplied with a copy of
the first catalogue issue offering each new revision of
Image Alchemy.
3. Others may only distribute Image Alchemy with the
written permission of Handmade Software. In all cases,
it must be clearly stated to the purchaser that he or
she is receiving an unregistered copy of a shareware
product
4. The distribution files must be distributed in their
original forms. The unrestricted version may not be
distributed.
If you received Image Alchemy as shareware (i.e. you downloaded
from a bulletin board, you received it from a friend, it came
with some hardware you purchased, or you bought a disk from a
software library), and if you use it beyond a two week trial
period, you must register the program using the accompanying
order form.
For the $79.95 registration fee, you will receive the current,
retail version of Image Alchemy without the 640 by 480 image size
restriction. You will be notified of significant upgrades to
Image Alchemy, you will be placed on a mailing list to receive
information about future products from Handmade Software, and you
will be entitled to phone and email support.
Registered users are entitled to minor updates for a nominal fee
(not to exceed $5.00 for disks or $20.00 for tapes). Registered
users are also entitled to major updates at a substantially
reduced price.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 2
What is Image Alchemy?
Image Alchemy is a software utility that has two functions in
life:
First, Image Alchemy performs JPEG compression. This is a new
standard for image compression that can achieve much higher
compression ratios than conventional compression techniques. It
achieves this high compression ratio by not entirely preserving
the original image (this is referred to as "lossy" compression).
For further information see the What is JPEG Compression section
below. Image Alchemy is the first shareware program to perform
JPEG compression and decompression.
Second, Image Alchemy converts between various graphics file
formats. Image Alchemy understands a wide variety of file
formats including industry standards such as GIF and TIFF.
Currently we support 15 different formats, and we are always
adding new formats; in fact, our goal is to have Image Alchemy be
able to read and write every type of graphic file in the world.
Hardware Requirements
IBM PC:
At least an 80286 IBM PC AT or clone.
At least 380k of free memory (Image Alchemy will run much faster
if you have more than 400k of memory available). Some
conversions and some images require more memory (Alchemy will
attempt to use all available system memory, so if you get out of
memory errors or warnings try removing as many TSRs as you can).
A hard drive with at least as much free space as three times the
size of the image being converting (i.e. a 640x480 image will
require approximately 1 meg of free space).
A VGA or 8514/A board, if you want to view images (tested VGA
boards include those with the Paradise, Everex, Trident, Video 7,
and the Tseng Labs Chipsets, tested 8514/A boards include IBM and
those with the Western Digital Chipset)
MS-DOS or PC-DOS 3.x or greater
Sun:
A SPARC or 680x0 equipped Sun (either a Sun 3, Sun 4,
SPARCstation, or SPARCserver).
SunOS 4.0.3 or greater
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 3
Introduction
To install Image Alchemy copy the file alchemy.exe (for MS-DOS
users) or alchemy (for Sun users) to your hard disk. There are
no support files or configuration files which need to be copied.
Image alchemy comes with a sample JPEG compressed image,
sample.jpg. You might want to copy it to your hard drive to
follow along with the examples below.
To use Image Alchemy:
alchemy -option [-option, ...] inputFileName [outputFileName]
The inputFileName is any valid file name (including an optional
path). The outputFileName is optional; if it is not specified
Image Alchemy generates one by substituting an appropriate
extension to the input file name. If the outputFileName does not
include an extension one will be added (you may prevent this by
appending a period "." to the outputFileName).
Options are preceded by a dash ("-"). Those options which take a
parameter may have it immediately following the option or
separated by a space (for example, either -c128 or -c 128 is
acceptable).
The only option that is required is the output file format (or
the viewing option, for IBM PC users). Image Alchemy will make
reasonable decisions for all of the other options.
The options are documented below. The order of the options is
only significant in the case of the -z, -D, and -V options. The
options can appear anywhere in the command line (certain options
take parameters; in this case the parameters must follow the
option). The case of the options is significant.
Three options which are unique in their operation are -z, -D, and
-V. These options all mean different things depending on how
many times they are specified (for example, -D 150, has a
different meaning then -D 150 -D 150). This isn't a problem in
actual usage, but is something you should be aware of.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 4
Image Alchemy Options
Information:
-h Help. Display command summary.
-? Display about information. Includes support, ordering,
and version information.
Output file options (details on each of the supported file
formats can be found below in the Details on Supported File
Formats section):
-a compressionType
Generate a tArga file. Optionally specify the
compression type used to store the file.
Compression types supported are:
0:Raw
1:RLE
The default is RLE Compression.
-e previewType
Generate an Encapsulated PostScript file. Optionally
specify the preview type. Preview types supported are:
0:None
1:Device Independent
The default is Device Independent
-g Generate a Gif file.
-i Generate an Ilbm file (also known as an Iff file, also
known as an LBM file).
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 5
-j[a] quality
Generate a Jpeg file. Optionally specify the use of
Arithmetic coding and the quality.
If you specify an a immediately after the -j (as in -
ja), Alchemy will generate a JPEG file compressed using
Arithmetic encoding instead of the default Huffman
encoding (see the JPEG section in the Supported File
Formats section below for more information).
Quality may vary between 1 and 100. The default is 32.
The higher the number the higher the quality of the
image and the lower the compression ratio. Quality
factors below 10 will produce images with significant
loss of quality.
Since JPEG compression was designed for use with
continuous tone images (such as produced by a scanner
or digitizer), poor results can be expected when
compressing line drawings. Alchemy will not compress
files which have less than 32 colours in them unless
you explicitly override this by using the -O option.
-k Generate a PBM/PGM/PPM file.
-l Generate a paLette file.
-m Generate a Macintosh pict file.
-n Generate an SilicoN Graphics Image file
-p Generate a Pcx file.
-P Generate a PCL file.
-r Generate a Raw file.
-s Generate a Sun raster file.
-t compressionType
Generate a Tiff file. Optionally specify the TIFF
compression type used to store the file.
Compression types supported are:
0:None
1:LZW
2:PackBits
3:Group III Fax
4:Group IV Fax
9:PICIO
10:SGI RLE
The default is LZW Compression.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 6
-w compressionType
Generate a Windows BMP file. Optionally specify the
BMP compression type used to store the file.
Compression types supported are:
0:None
1:RLE
The default is None.
Palette Options:
-24 Specify that the output file should be 24 bit (true
colour). This is the default for JPEG files (which
must be 24 bit) and is not allowed for GIF and PCX
files (which must be paletted). The other file
formats, which may be either 24 or 8 bit, default to 24
bit if the input file is 24 bit (certain file formats
may only be 8 bits if the images are grey scale, in
that case Alchemy will automatically switch to true
colour for output).
-8 Specify that the output file should be paletted (up to
8 bits). This is the default for GIF and PCX files and
is not allowed for JPEG files. The actual number of
bits is determined by the -c option (below). If the
input file is true colour the output file will be
quantized and dithered (see the -c and -d options
below).
-b Specify that the output file should be grayscale. If
the input is paletted or a -8 is specified, -c can be
used to specify the number of gray levels.
-c colours
Specify the number of colours for the output file.
Only applicable for paletted files (see -8, above).
The number of colours may be between 2 and 256.
If the input file has a larger number of colours than
specified for the output file, the image will be
quantized using Heckbert's median cut algorithm and
dithered (see -d, below).
Converting an image with a large number of colours to a
small number of colours (less than 8) may give poor
results.
For further information on Heckbert's median cut
algorithm see the Colour and Dithering section below.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 7
-d ditherType
Specifies the type of dithering, if any, to apply to
the image.
DitherType can be:
0:None
1:Floyd-Steinberg
2:Stucki
3:Jarvis, Judice, & Ninke
The default is Floyd-Steinberg.
Floyd-Steinberg is the fastest (except for no
dithering) and usually produces the best results.
Stucki and Jarvis, Judice, & Ninke both tend to cause
an image to appear more grainy on low resolution output
devices (such as CRTs). However they produce better
results than Floyd-Steinberg on high-resolution low
colour devices such as laser printers.
This option only has an effect if the number of colours
is being reduced or the image is being remapped to a
new palette. Dithering is used to reduce colour
banding in an image caused by the palette not having a
perfect match for every colour in the image. However,
dithering does take time and can cause the image to
look grainy, so it can be disabled.
For further information on dithering see the Colour and
Dithering section below.
-E Convert image for best possible quality viewing using
an EGA board and monitor. This option reduces the
palette resolution to 2 bits and automatically
specifies the following: -8 -c16 -z0 -z1 -z0.
The -c16 option can be overridden by using an explicit
-cn option (but n has to less than 16).
-f filename
Match the output to a palette read from a file. The
input image will be remapped to use the palette found
in the specified filename. This can be useful if you
are combining several images into a collage or want to
match an image to a pre-existing palette. The
resulting image will be dithered (unless you specify no
dithering by using the -d option).
-F filename
False colour an image using the palette from a file.
The input image will be changed to use the palette
found in the specified filename but no attempt at
picking the best match will be done. This feature can
be used to add false colour to monochrome images. The
output file is not dithered. Only applicable to
paletted input files.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 8
-u Use a Uniform Palette. Instead of using the Heckbert
median cut algorithm to generate a palette for the
image use a palette with entries which are evenly
distributed in the RGB colour cube (actually the cube
is distorted because the human eye is not equally
sensitive to red, green, and blue). The advantage of
using a uniform palette is that it's fast because a
custom palette need not be generated. However, this is
at the expense of image quality since the palette isn't
generated based on image content. When just viewing a
true colour image on a paletted display a uniform
palette is used.
The -c option can be used in conjunction with -u to
specify the size of the uniform palette; in that case
Image Alchemy will generate a palette with not more
than the specified number of colours (but not less than
8). The palette size will not necessarily match the
specified size, as the actual size must be the product
of three integers, and Alchemy will attempt to pick
integers that roughly correspond to the sensitivity of
the human eye to red, green, and blue (30%, 59%, and
11%).
-z sortType (first usage)
Sort the image palette. This option only has an effect
if the palette is being generated by Image Alchemy
using Heckbert's median cut algorithm. SortType can
be:
0:None
1:popularity
2:luminance (white to black)
3:rgb
4:luminance (black to white)
The default is None.
See below for an example of the -z option.
-z selectionType (second usage)
If you specify a Palette sort parameter you may also
specify a palette selection parameter. SelectionType
can be:
0:mean
1:median
2:corner
The default is mean.
See the Colour and Dithering section below for an
explanation of these choices.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 9
-z swapType (third usage)
If you specify both a Palette sort parameter and a
Palette selection parameter you may also specify a
palette swap parameter. SwapType can be:
0:None
1:IBM (colour 0 is black, 7 is white)
2:Macintosh (colour 0 is white, 255 is black)
3:Sun (colour 0 is white, 1 is black)
The default is based on the file type being written out
(IBM for Gif, Macintosh for Mac PICT, Sun for Sun
Raster, and None for all others).
Example: for the -z option(s):
-z4 -z0 -z3 :sort colours by luminance, use the
mean of the Heckbert box for the colour, and move the
colours around so that the lightest colour is colour 0
and the darkest colour is colour 1.
Note that it is not possible to specify a swapType
without first specifying both a sortType and a
selectionType. See the Colour and Dithering section
below for more information.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 10
Misc Options:
-D aspectRatio
Specify aspect ratio for the output image. The aspect
ratio of an image is the ratio of the width of a single
pixel to the height of a single pixel. This option
lets you specify this ratio when writing a file or
displaying an image (the only file types which support
aspect ratio are JPEG, TIFF, Raw, Mac PICT, ILBM, and
Targa; specifying this option when writing out other
files will have no effect). Ordinarily aspect ratio is
specified as two numbers separated by a colon, for
example 1:1 or 1:1.2. However to simplify the user
interface Alchemy expects a single number which is the
percentage of the width of a pixel to its height (so to
specify 1:1.2 use -D 83, since 100/1.2 is 83).
Example: if you are converting a 640x350 IBM EGA PCX
image (which has an aspect ratio of 35:48) to a TIFF
image you can say -D 73 (73 is 100/48*35) and the TIFF
image will have the correct aspect ratio and an
intelligent TIFF reader will make use of the
information. Alchemy attempts to preserve aspect ratio
whenever possible, but since so few file formats have
aspect ratio information this hardly ever happens.
This option can also be used when displaying an image
on an IBM PC. See the Display options section below
for more information.
-D dotsPerInchX -D dotsPerInchY
Specify image resolution in dots per inch. You must
specify both dotsPerInchX and dotsPerInchY, even if
they are the same. This option is ignored when writing
a file format which does not have image resolution (the
only have formats which include image resolution are
JPEG, Raw, TIFF, and Mac PICT). Reasonable values to
use for dotsPerInch include: 72 (the resolution of a
13 inch monitor display 640x480) and 300 (the
resolution of a laser printer). Alchemy will preserve
this information when converting files whenever
possible.
Note that it is not possible to specify both an aspect
ratio and a dots per inch value for an image. This is
because specifying a dots per inch value automatically
implies an aspect ratio. And in fact there are no file
formats which support independent aspect ratio and dots
per inch values.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 11
-o Overwrite output file if it exists. Image Alchemy will
not overwrite an existing file unless the -o option is
specified.
-O Override JPEG compression warning. See the -j option
above for information.
-q Apply Smoothing when decompressing a JPEG image.
Because JPEG compression works on 8x8 pixel blocks
there tend to be discontinuities at the edges of these
blocks producing block artifacts. Smoothing attempts
to reduce these artifacts. Smoothing is really only
necessary at very low quality settings (Q less than
10); even then the effects are not particularly
significant.
-x Display image statistics. Displays image type, size,
number of colours, aspect ratio, and compression ratio.
Can not be combined with other options.
-X pixels
Change the horizontal dimension of the image to the
specified number of pixels. Currently Alchemy does
simple pixel replication or elimination. Future
versions will allow more complex types of scaling in
both dimensions.
-Y pixels
Change the vertical dimension of the image to the
specified number of pixels. Currently Alchemy does
simple pixel replication or elimination. Future
versions will allow more complex type of scaling.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 12
Display options (IBM PC only):
In addition to the file conversion options listed above Image
Alchemy can display images on a VGA or 8514/A equipped IBM PC.
The current version of Image Alchemy supports 320x200x256,
640x400x256, and 640x480x256 display modes for VGA and
640x480x256, 1024x768x256, and 1280x1024x256 display modes for
8514/A (the exact resolutions supported depend on the model board
installed).
Because of various incompatibilities between different VGA boards
640x400x256 and/or 640x480x256 mode is not supported on all
boards and has not been tested on all boards that are supported.
The 320x200x256 mode is a standard VGA IBM mode and should work
on all VGA boards. VGA boards which have been tested for the the
higher resolution modes include Paradise, Tseng Labs 3000 & 4000,
Video 7, Trident, and Everex chipset based VGA Boards. Support
for others is included but has not been tested and may be
accessed through the -vv option (see below).
Image Alchemy requires AI to be installed to use 8514/A displays
which aren't based on the Western Digital chipset (Alchemy should
also be able to display on AI compatible boards which are not
8514/A (such as 340x0 based boards), but this has not been
tested). For Western Digital based 8514/A boards, no driver is
required.
Alchemy checks for a display board in the following order:
Western Digital 8514/A, AI based 8514/A, extended VGA, standard
VGA. Alchemy automatically uses the lowest resolution mode which
will display the entire picture.
The image will be centered in the display (for images which are
larger than the display Alchemy will center the display in the
picture).
-v horizontalResolution
View file using high resolution mode (640x400x256 or
640x480x256 for VGA, up to 1280x1024x256 for 8514/A).
If displaying on a Western Digital chipset 8514/A an
optional parameter may follow the -v command. This
parameter specifies horizontal resolution and may be
either 640, 1024, or 1280. The default is to use the
lowest resolution which can fit the entire image. If
the image is true colour, a uniform palette will be
used and the image will be dithered (dithering may be
disabled by use of the -d option, see above). See the
Colour and Dithering section below.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 13
-vv Force view. If Image Alchemy can identify the VGA
board you have installed and has support for it, but
has not been tested with it, you will be given the
option of rerunning the program with the -vv option
instead of the -v option. This will force viewing of
the file.
Please contact Handmade Software if you use this option
and viewing works correctly on your VGA board so that
we can add it to the list of tested boards.
-V View using 320x200x256 mode. This is a standard VGA
mode which works on all VGA boards (including those
built-in to PS/2 computers). This command is most
useful combined with the -V option below.
-V Scale image to fit on monitor and correct aspect ratio.
After specifying the view type, -v, -vv, or -V, you may
also specify that the image should be scaled to fit on
the display by using a second -V option (which means
you end up typing -v -V, -vv -V, or -V -V).
This command will scale the image and correct the
aspect ratio of the image by removing rows and/or
columns from the image.
Note that this option can also be useful for displaying
images which are not larger than the screen but which
have an aspect ratio different than the display.
Also note that Alchemy assumes that the aspect ratio of
a display pixel is 1:1 when in 640x480 mode and 1:1.2
when in 640x400 mode or 320x200 mode. Furthermore
Alchemy assumes that the aspect ratio of pixels in
640x400 and 320x200 images is 1:1.2 and the aspect
ratio of pixels in 640x350 images is 35:48. You can
override any of these assumptions with the -D option
(for a further discussion of aspect ratio see the -D
command, above).
Don't worry if this is confusing; in practice Alchemy
deals with everything automatically if you use the
second -V option (there is however a problem with
display 320x400 IFF and HAM files, see the Answers to
Frequently Asked Questions section below for more
information).
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 14
Examples
To convert the JPEG file sample.jpg to a Targa file called
sample.tga use the following command:
alchemy -a sample.jpg
To convert the 24 bit Targa file sample.tga to a 256 colour Gif
file called new.gif:
alchemy -g sample.tga new.gif
To convert the 256 colour Gif file, new.gif, to a 64 colour PCX
file called new.pcx:
alchemy -p -c64 new.gif
To view the Gif file new.gif (only applicable on IBM PCs with
appropriate VGA board):
alchemy -v new.gif
To convert sample.jpg to a black and white, two colour GIF file
use a text editor to create a file called BW.PAL which contains
the following:
PAL
2
0 0 0
255 255 255
then:
alchemy -g sample.jpg -f bw.pal
(Or, you could have said alchemy -g sample.jpg -b -c2, but that
wouldn't have demonstrated the -f option).
To view the resulting file in 320x200x256 mode, scaling the image
to fit the display:
alchemy -V -V sample.gif
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 15
Details on Supported File Formats
Image Alchemy currently has support for the image file formats
listed below. Where we know of restrictions or limitations they
are listed. If you have trouble reading in and image in one of
the file formats we claim to support please contact us (see What
if Image Alchemy Messes Up, below).
Image Alchemy identifies the type of file being read by checking
various magic numbers and other information that varies from
format to format. It is possible for Image Alchemy to
incorrectly identify a file; if this happens please contact us.
.BMP Windows BitMaP
Microsoft Corporation
Reads and writes 1, 4, 8, and 24 bit files. Reads and
writes RGB (raw), RLE4, and RLE8 files.
Since no Windows 3.0 software we have (including the
Windows 3.0 supplied utilities) can read nor write RLE4
or RLE8 files, writing RLE compressed files is not
recommended because that option has not been tested
(Alchemy can read RLE files that it wrote, but that
isn't a very significant test).
.EPI Encapsulated PostScript
.EPSI Adobe Systems Incorporated
Output only.
Writes Encapsulated Postscript files. If the output
file is grayscale, it will work with any PostScript
device (grayscale output can be forced with the -b and
-8 options). If it's truecolour, then the CMYK
extensions or a level 2 device is required. For
paletted files, a level 2 device is always required.
Colour files can be forced to produce EPS files
requiring only the CMYK extensions by using the -24
option.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 16
.JPG Handmade Software JPEG Files
Handmade Software, Inc.
Joint Photographic Experts Group (JPEG) JPEG-8-R8 draft
standard.
Reads and writes baseline JPEG with YCbCr CCIR-601
colour space, interleaved components, Huffman or
Arithmetic encoded. Image Alchemy can read files with
any component subsampling up to 4x4; it always writes
2h:1v 1h:1v 1h:1v. For grayscale images, it uses a
single component. Image Alchemy can only recognize
grayscale files if the input is either paletted or 8
bit grayscale. Image Alchemy Huffman encoded JPEG
files comply with the industry standard `JFIF'
interchange format.
Grayscale images that have been JPEG compressed will
decompress as paletted images (with a 256 level
grayscale as a palette); others will be 24 bit.
JPEG files can be Huffman or Arithmetic encoded.
Arithmetic encoding has the advantage of making the
file approximately 20% smaller, but has the
disadvantage of taking approximately 10% longer to
compress and decompress and the resulting file will no
longer be JFIF standard.
.IFF Interchange File Format/InterLeaved Bit Map
.LBM Commodore-Amiga Corp.
Reads 1 through 8 bit, 24 bit, and Ham images; writes 1
through 8 bit and 24 bit images. If you're writing an
Ilbm file for use on an Amiga, you probably want to
write either a paletted file with 32 colours or a 24
bit file. 24 bit Ilbm files can then be converted to
one of the Amiga specific display modes with various
third-party utilities.
.GIF Graphics Interchange Format
CompuServe, Incorporated.
Reads and writes 1 bit through 8 bit GIF87A files,
reads 1 through 8 bit GIF89A files (discarding all but
the first image). Reads both non-interleaved and
interleaved files; writes non-interleaved files.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 17
.PAL HSI Palette Files
Handmade Software, Inc.
Contain only Palette Information.
Useful in conjunction with the -f option (see above).
PAL files are ASCII files which can be edited with a
text editor.
The PAL file format: the first line contains the
letters "PAL", the next line contains an integer
indicating the number of palette entries, the rest of
the file consists of lines of 3 numbers each (separated
by spaces), representing the red, green, and blue
values for each of the colours (the numbers vary
between 0 and 255; 0 0 0 is black, 255 255 255 is
white, 255 0 0 is bright red, etc.). See the Examples
section above for a sample PAL file.
Converting a .PAL file to another image format is
allowed but doesn't make much sense (since there won't
be any image data).
.PCL HP Printer Command Language
Hewlett-Packard Company
Reads and writes 1 bit files (PCL files must be 1 bit,
black and white; if you attempt to write out any other
file type Alchemy will automatically switch to that
mode).
Only pays attention to raster images in the file;
attempts to skip everything else. Due to the enormous
number of options allowed in PCL files this option has
not been thoroughly tested. See the Answers to
Frequently Asked Questions section below for more
information.
.PCX PC Paintbrush
ZSoft Corp.
Reads and writes 1, 4, and 8 bit images.
PCX format files are often written out incorrectly;
Alchemy attempts to figure out what is wrong and make
intelligent decisions (things Alchemy can deal with
include PCX files without palettes, files missing the
last line of image data, and files with illegal (and
incorrect) combinations of bits per pixel and planes).
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 18
.PICT Macintosh PICT format
.PIC Apple Computer, Inc.
Reads 1, 2, 4, 8, 16, and 32 bit images; writes 1, 2,
4, 8, and 32 bit images.
Only pays attention to pixMaps in the pict; attempts to
skip everything else. Due to the enormous number of
options allowed in PICT files this option has not been
thoroughly tested. See the Answers to Frequently Asked
Questions section below for more information.
.PBM Portable BitMap
.PGM Portable GrayMap
.PPM Portable PixelMap
.PNM Portable aNyMap
Jef Poskanzer's Portable BitMap Package
Reads and writes 1, 8 (grayscale only), and 24 bit
RAWBITS (binary) images. For more information on the
Portable BitMap Package see the References section
below.
.RAST Sun Raster Files
.RAS Sun Microsystems, Inc.
Reads 1, 8, 24, and 32 bit images. Writes 1, 8, and 32
bit images.
Supports Standard, BGR, RGB, and Byte Encoded (RLE)
files.
.RAW HSI Raw Files
Handmade Software Inc.
Reads and writes 8 and 24 bit images. Used internally
by Image Alchemy when converting between certain
combinations of other formats. Can also be explicitly
read and written. If you are interested in adding HSI
Raw support to your software please contact us for more
information.
.SGI Silicon Graphics Image Files
Silicon Graphics, Inc.
Reads and writes 1, 8 (grayscale only), and 24 bit
files. Reads Verbatim (uncompressed) and RLE files.
Write uncompressed files.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 19
.TGA Targa Files
Truevision Corp.
Reads 8, 15, 16, 24, and 32 bit images, ignoring the
alpha channel for 32 bit images; writes 8 and 24 bit
images. 8 bit output files are paletted unless the
palette is all gray, in which case the output is a
grayscale file.
.TIFF Tagged Image File Format Files
.TIF Microsoft Corp. and Aldus Corp.
Reads 1, 4, 8, 24, and 32 bit images (ignoring the
alpha channel for 32 bit images); writes 1, 4, 8, and
24 bit images. Can read TIFF class B, G, R, and some P
(those with 1, 4, or 8 bits per pixel) files. Writes
class B, G, P, and R files, depending on the input file
and options specified.
1,4, and 8 bit output files are paletted unless the
palette is all gray, in which case the output is a
grayscale file. Output compression types supported are
raw, LZW, PackBits, Group III fax, Group IV fax, PICIO,
and SGI RLE. Input compression types supported are
raw, LZW, PackBits, Group III fax, Group IV fax, CCITT
RLE (both byte and word aligned), NeXT, Thunderscan,
PICIO, and SGI RLE.
General Notes:
Image Alchemy automatically recognizes and reads MacBinary files
(MacBinary files are generated when you accidently leave
MacBinary mode on when transferring a file from a Macintosh).
Gamma, aspect ratio, and resolution values are preserved whenever
possible.
Colour correction tables are currently ignored.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 20
Colour and Dithering
Colour images are normally stored in one of two ways: as an array
of direct colour values (usually red, green, and blue) (referred
to as a truecolour file in this document) or as an array of
indices into a colourmap which contains red, green, and blue
colour values (referred to as a paletted file in this document).
The only reason for the existence of paletted images is that they
take less memory, so the hardware to display them is cheaper.
The dominance of paletted hardware is changing as the price of
memory and the processing power it takes to update large amounts
of memory at a reasonable speed drops (a Targa 32 board is an
example of a truecolour board, a VGA board is an example of a
paletted board). However, until truecolour graphics devices
become the norm, there's a need to convert images from truecolour
to paletted. This conversion is done in two steps: the first is
to generate a palette for use by the image; the second is to map
the image to the new palette.
Image Alchemy supports two methods of generating a palette. The
simplest and fastest method is to use a palette containing
colours which are uniformly distributed in the RGB cube, referred
to as a uniform palette. This has the advantage that it's fast
and the same palette can be used for any image; the primary
disadvantage is that most images don't contain colours from
everywhere in the RGB cube, so this palette wastes entries
representing colours that aren't needed for the particular image
being converted.
Image Alchemy also supports Heckbert's median cut algorithm.
This algorithm first builds a three dimensional histogram
indicating how popular any given colour in the RGB cube is in the
image being converted. It then proceeds to subdivide this
histogram cube (by dividing boxes in half) until it has created
as many boxes as there are palette entries. The decision as to
where to divide a box is based on the distribution of colours
within the box. This algorithm attempts to create boxes which
have approximately equal popularity in the image. Palette
entries are then assigned to represent each box. There are other
methods of generating a palette from an image, but Heckbert's
algorithm is generally regarded as the best tradeoff between
speed and quality.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 21
You can change the method used to select a colour for each box by
use of the -z options. The default method is to use the mean of
all the colours in the box (this gives the mathematically correct
result). However for some images slightly better results can be
obtained by using the center of the box (without regard to where
the pixels are in the box). For images with a very small number
of different colours (less than 16) better results can be
obtained by using a corner of the box (the boxes tend to be large
when reducing an image to a small number of colours; picking a
colour near the center of the box will give you muddy colours, by
using the corner of the box you get more saturated colours).
The next step is to map the image to the new palette; this is
where dithering becomes important. The simplest approach is to
map every colour in the original image to the palette entry which
is closest to it (which Image Alchemy does if you specify no
dithering). However, since the palette entries generally
represent several different colours in the original image, this
results in colour banding (where areas of smooth colour changes
in the original become areas of one solid colour in the paletted
version). This can be alleviated by dithering (or modulating)
the image data such that any given pixel may not be mapped to
it's closest palette entry, but the average over some area of the
image will be closer to the correct colour than it would
otherwise be. Image Alchemy uses a class of algorithms called
"error-diffusion" to do dithering. These algorithms work by
using the closest palette entry to a colour and then distributing
the error (the difference between the desired colour and the
chosen palette entry) to the pixels below and to the right of the
current pixel. This process is repeated for every pixel in the
image, using the colour values which have been modified due to
the error from previous pixels.
For more information on Heckbert median cut and dithering see the
appropriate reference listed in the References section below.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 22
What is JPEG Compression?
J.P.E.G. stands for the "Joint Photographic Experts Group". This
is a group of experts who defined a standard compression scheme
for still images, commonly called JPEG Compression. Currently
the standard is still in draft form. The standard will hopefully
be finalized in 1991.
JPEG Compression consists of a series of reasonably complex
mathematical operations. These include colour space conversion,
Discrete Cosine Transform, quantization, and Huffman or
Arithmetic encoding. After these steps you end up with an image
which takes fewer bits to store than you started out with.
However, when you decompress a JPEG compressed image you end up
with an image that is not quite the same as the original image
(which is why JPEG Compression is referred to as "lossy"). You
might well ask why anyone would want to compress an image using a
lossy technique? It turns out that lossy compression ratios are
much better than lossless compression ratios and the loss is
generally very small. And, in fact, every operation of
converting an image is lossy (the original photographic or
electronic process which captured the image was lossy, scanning
or digitizing the image was lossy, displaying the image on a
monitor is lossy, and printing the image is lossy).
JPEG compression typically involves the following steps:
1. The image is converted to a colourspace with separate
luminance and chrominance (Image Alchemy uses CCIR-601
YCbCr). This is done because the luminance information (Y)
is far more important to the human eye than the chrominance
information (Cb and Cr); by separating them it's possible to
compress the chrominance information more than the luminance
information. This step is not specified in the JPEG draft
(it doesn't discuss colourspace at all), but is standard
practice.
2. The luminance and chrominance information are seperately
transformed to the frequency domain using a discrete cosine
transform acting on 8x8 pixel blocks (the chrominance
information may be subsampled first).
3. The transformed data is quantized (which simply means some
information is thrown away). The samples representing
higher frequencies are generally quantized more than those
representing low frequencies.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 23
4. This quantized data is then compressed using an entropy
encoder (Huffman and Arithmetic coding are allowed by the
draft JPEG standard; only Huffman is allowed by the JFIF
standard).
This data then corresponds the JPEG Interchange Format and is
ready to be stored in a file. However the JPEG Interchange
Format does not include enough information to actually be able to
convert the file back to an image. Specifically the colourspace
used and the aspect ratio or the resolution of the image are not
included. Until recently there was no standard way of putting
this information in a JPEG file. On March 1, 1991
representatives of several JPEG hardware and software developers
(including C-Cube, Radius, NeXT, Storm Tech., the PD JPEG group,
Sun, and Handmade Software) got together at C-Cube and
established the JPEG File Interchange Format (JFIF). If you
would like more information on the JFIF standard please contact
us.
If you are interested in getting a copy of the the current draft
JPEG standard contact:
X3 Secretariat
Computer and Business Equipment Manufacturers Institute
311 First Street NW, Suite 500
Washington, DC 20001-2178
The last time we talked with them the charge was $8.00,
including shipping.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 24
Answers to Freqently Asked Questions
Q: When I convert a gray-scale Gif file to a JPEG file and then
back to a Gif file the final Gif file is twice the size of
the original. Why is this?
A: The input Gif file was probably a 16 or 32 colour gray scale
file. When you converted it to a JPEG file the number of
colours in the file was lost (JPEG gray scale files are
always 256 colour). When the JPEG file was converted back
to a Gif file Alchemy assumed you wanted 256 colours in the
file. And a 256 colour Gif file is bigger than a 16 colour
Gif file (because of the way Gif compression works). To
prevent this you can use a -c32 option in the command line;
this forces Image Alchemy to use that many colours for the
output file.
Q: Why can't PHIPS read the Targa file I wrote with Image
Alchemy?
A: Some software which reads Targa files can not handle
compressed files. By using -a0 instead of just -a, Image
Alchemy will write out an uncompressed Targa file. In
addition, some software can read true colour Targa files,
but can not read paletted or gray scale files. Image
Alchemy can be forced to write out a true colour file by
using the -24 option.
Q: Why is decompressing or compressing a JPEG image so slow?
A: There are a large number of calculations that have to be
done during JPEG compression. This is an inherent
limitation of JPEG compression. Image Alchemy has been
optimized quite a bit to reduce the number of calculations,
and we are working to further reduce the number of
calculations. If you are transferring files over modems or
storing them on slow media (tape) the compression times are
usually more than made up for by the decrease in
transmission or retrieval times.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 25
Q: Why can't my favorite desktop publishing package read the
TIFF file I wrote with Image Alchemy?
A: TIFF is an extremely versatile standard; it can handle
anything from 1 bit images to full colour images with an
alpha channel and TIFF allows many different types of
compression. Unfortunately this versatility means that it's
difficult for a single piece of software to be able to read
in every valid TIFF file.
If the software specifies the classes of TIFF it can read,
you can force Alchemy to write out a specific TIFF class by
using the following options:
class B: -8 -b -c2 -t2 (preferred if input is
bilevel)
class G: -8 -b -t1 (preferred if input is
grayscale)
class P: -8 -t1 (preferred if input is
paletted)
class R: -24 -t1 (preferred if input is true
colour)
If the supported classes are not specified experiment with
various combinations of -24, -8, -b, and -cn. In this case
it is usually best to use no compression (-t0) while
experimenting with the other options, as many TIFF readers
have difficulty with compressed files. When you find a set
of options that works, then you can try various compression
modes to save space. Be aware that using -b will force the
output file to be gray scale and you will lose all the
colour information in the file (most DTP programs only have
support for gray scale TIFF files).
You may also have to use the -Dn -Dn option to specify the
resolution of the image (this is especially true when
converting from a file format which does not have a value
for image resolution). You can generally tell if this is
necessary because the program you are using to read in the
TIFF file will claim that the file is unreasonably large or
small. Generally, if you are using a 300 DPI Laser Printer
you want to make the TIFF file 300DPIx300DPI (-D 300 -D
300).
If you would like further information specific to using
Image Alchemy with your word processor or desktop publishing
program please contact us; we will be maintaining a list of
how to make Alchemy work with other software packages.
Similarly if you figure out how to import files into a
specific package let us know and we will add your tips to
our documentation.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 26
Q: When I convert a 32 bit Targa file to a PCX file and then to
a JPEG file it doesn't look nearly as good as if I convert
the Targa File directly to the JPEG file. What can I do to
maintain high quality in JPEG compressed files?
A: When the Targa file was converted to the PCX file Image
Alchemy had to reduce the number of colours in the file (the
original Targa File had up to 16 Million Colours, PCX files
are limited to 256 colours). This step is known as colour
quantization (Image Alchemy uses the Heckbert Median Cut
method for quantization, see the Colour and Dithering
section above). The difficulty with colour quantization is
that it leaves artifacts known as colour banding. To reduce
this phenomenon Image Alchemy dithers the image (you can see
the effect of colour banding by turning off dithering by
using the -d option). Unfortunately a dithered image does
not JPEG compress very well (dithering adds a lot of high-
frequency information to an image; JPEG compression attempts
to remove much of that information). In addition JPEG
images are always continuous colour images, so when the JPEG
file is decompressed it has to be colour quantized and
dithered again. Dithering a previously dithered image
reduces the quality even more. The solution is to use the
best starting quality you can for JPEG compression, ideally
a continuous tone image. The compressed image size will be
smaller than if you had started with a paletted image and
the quality will be better.
Q: When I view a JPEG compressed image on my VGA board the
quality isn't nearly as good as when I first convert it to a
Gif file and then view it. Why is this?
A: To save time Alchemy automatically uses a uniform palette
when you are just viewing the image. When converting to a
different file format Alchemy does Heckbert quantization to
generate a palette. The difference in image quality is the
difference between using a uniform palette and an optimum
palette. See the Colour and Dithering section above for
more information on palette generation.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 27
Q: I've converted a Mac PICT file to a Gif file, but the Gif
file is missing some or all of the information that was in
the PICT file. What happened to it?
A: PICT files are a combination of drawing commands (such as
lines, rectangles, and circles) and raster areas (called
pixMaps). Alchemy can only read the raster portion of the
files. Programs such as MacDraw and MacDraft write out
files with drawing commands, programs such as MacPaint write
out files which are entirely raster areas (pixMaps), and
some programs, such as SuperPaint can write out files which
are either or a combination of both. If you are using such
a program check the documentation on how to write out files
in "paint" mode.
Q: I've converted an HP PCL file to a Gif file, but the Gif
file is missing some or all of the information that was in
the PCL file. What happened to it?
A: PCL files have the same problem as PICT files (see above);
they are a combination of drawing commands (such as lines
and rectangles) and raster areas (called rasters) and
Alchemy can only convert the raster areas in PCL files. In
addition they contain a lot of font and text information,
which is also lost. Unfortunately there isn't any general
way to preserve this data.
One way which works under Microsoft Windows 3.0 is to
install Adobe Type Manager (ATM). ATM automatically
intercepts any text commands and converts them to rasters.
And in fact, the standard Windows 3.0 HP PCL driver only
generates rasters. So the file will appear in its entirety
when converted by Alchemy. Contact us if you want further
information on using Alchemy with Windows 3.0.
Q: I keep getting "Out of Memory trying to ..." messages.
Help!
A: Image Alchemy is running of of memory. First attempt to
maximize the amount of memory available by removing as may
TSRs as you can. If this doesn't help please contact us
with the following information: your computer configuration
(amount of available memory, size of hard disk), operating
system version, and what you are trying to do (input file
information (size of image and type of file) and options
specified). Alchemy can generally convert images as large
as 2000 pixels across and an infinite number of pixels down.
However there are certain conversions which require more
memory than others.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 28
Q: Why can't Image Alchemy read in JPEG files produced by
Kodak's ColorSqueeze (or Sun's VFCtool)?
A: The JPEG standard is still in draft form. Until it is a
mature standard various manufacturer's will implement
different versions of it. As of March 1, 1991 Image Alchemy
currently supports the JFIF format and should work with any
other JPEG software which also claims JFIF compatibility.
If other software you are using claims to support the JFIF
format and you are having trouble please contact us. If the
other software does not support JFIF contact the
manufacturer and tell them they should send you an update
which supports JFIF (you can tell them to contact us if they
need a copy of the JFIF standard).
Q: I told Alchemy to convert a PCX file to an 8 bit Gif file
(using the -8 option). Yet when I get statistics on the
file (using -x) Alchemy reports the file has 16 colours?
A: Alchemy will always store the file using the smallest bits-
per-pixels allowable for the given image (this results in
the smallest possible file). In this case the input file
only had 16 colours in it.
Things can get more unpredictable with formats such as Sun
Raster (which require 1 bit files to be black and white) and
SGI (which requires 8 bit files to be grayscale). In these
cases Alchemy will always do the best it can (giving you a
warning message if it does something which may surprise you
later).
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 29
Q: I converted a PCX file with 16 colours to a 16 shade gray
TIFF file using the -b and -p options. The 16 colour PCX
file had some shades of gray in it which were changed in the
TIFF file. How can I prevent this?
A: The short answer is: you can't. The long answer is: there
is a work around.
The problem is that gray-scale TIFF files have a uniformly
spaced gray palette (this is required as part of the TIFF
standard). So if you create a 16 shade gray TIFF file it
will have the following shades of gray in it: 0, 17, 34, 51,
68, 85, ..., 255. However the 16 colour PCX file you
started with probably didn't have those exact colours in it
(for example, PCX files written out by Windows 3.0 Paint
have shades of gray which correspond to 0, 128, 192, and
255). So Alchemy did the best it could and matched the
input colours to the output colours.
The solution is to tell Alchemy to write out a 256 colour
gray scale TIFF file (which you do by adding a -c256 to the
-b and -t options). This file still has a uniform gray
palette; but that palette now contains every colour: 1, 2,
3, 4, ..., 255. So Alchemy can map the colours 128 and 192
to their exact match. This does have the disadvantage of
making the resulting 256 colour TIFF file twice as large as
the 16 colour TIFF file; but this is the only way to
guarantee that Alchemy can find an exact match for all the
shades of gray in the input file.
Q: Why do you only allow specifying image resolution in Dots
Per Inch? Don't you realize that most of the world is
metric?
A: Yes, we do realize that the entire world, with the exception
of the United States and Great Britain, claims to use the
metric system exclusively (and Great Britain will presumably
change in 1992). However this isn't true. A laser printer
manufactured in Japan is still 300 dots per inch (not
11.811... dots per mm) and a 19 inch monitor sold in Europe
is called a 19 inch monitor (actually a 19 inch monitor is
called a 20 inch monitor in Europe, they measure the total
picture tube diagonal, not just the viewing area). And this
even applies to non high-tech things: the wheels on my
German car are 16 inches in diameter (though the tires I buy
for it are 225 mm wide, even in the United States).
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 30
Q: I am using Alchemy to display a 320x400 IFF image created by
an Amiga. When I use just the -v option the image comes out
tall and skinny. When I use the -v -V option, which is
supposed to correct the aspect ratio, instead of things
getting better they get worse (the image is even skinnier).
What's going on?
A: As near as we can tell Amiga software has a different idea
of what aspect ratio is than the rest of the world.
For displays aspect ratio is defined as the ratio of the
width of a single pixel to the height of a single pixel. So
if you have square pixels (which you do on a standard
monitor in 640x480 mode) the aspect ratio is 1 to 1 (usually
written as 1:1). When you change display modes you are
generally not changing the height and width of the total
display area; what is changing is the width and height of
each pixel, so the aspect ratio changes. For example, a
640x400 display has an aspect ratio of 1:1.2 (that means
each pixel is 1.2 times as tall as it is wide (which makes
sense since 480/400 equals 1.2)). A 640x200 display
(remember IBM CGA graphics mode?) has an aspect ratio of
1:2.4 (which is a pretty extreme aspect ratio). Now this is
where it gets interesting.
The aspect ratio number stored in Amiga IFF files for
320x400 images is 1:1.1, which means the pixels are 1.1
times as tall as they are wide, so therefore the actual
image should be the equivalent of a 320x440 image with
square pixels. And this is what Alchemy will attempt to
display when you use the second -V (actually Alchemy never
makes any dimension larger, so the actual image Alchemy
displays is 291x400, which is the same ratio as 320x440).
However this is obviously wrong, as you can tell when you
actually look at an image. As near as we can tell the
actual aspect ratio of these images is 5:3 (the math we used
to come up with this number is 640/320:480/400). And in
fact if you tell Alchemy to override the aspect ratio by
using a -D 167 option (167 because 5/3*100 is 166.6666) the
image displays correctly. Why Amigas create images which
claim they are 1:1.1 remains a mystery.
Q: Do you give multiple copy discounts? Do you have site
licenses? Are you interested in licensing the source code?
A: Yes. Yes. Yes. Contact us for more information.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 31
Version History
v1.4 03/18/91
Released for Sun SPARC, Sun 3, and IBM PC.
Format changes:
Added Arithmetic coding and decoding for JPEG compression.
Added 1 bit PCX file support.
Added new compression types to Targa.
Added PBM/PGM/PPM support.
Added GIF89A support for reading.
Added SGI support.
Added Windows BMP support.
Added writing Group III, Group IV, PICIO, and SGI RLE Tiff
compression types.
Added Encapsulated PostScript output.
Added HP PCL support.
Display option changes:
Added support for Video 7, Trident, Tseng 4000, IBM 8514/A
display boards.
Added 320x200x256 display mode.
Added image scaling during display (which allows display of the
entire image on the screen and preserves aspect ratio).
Center images on screen during displaying.
During display the screen is now cleared to the darkest colour.
Misc changes:
Added image scaling
Added conversion to monochrome images.
Preserve and allow specification of aspect ratio or dots per
inch.
Added false colour palette conversion.
Added optimized EGA image generation support.
Added support for very large images.
Added palette sorting, paletted swapping, and palette selection
parameters.
Added Stucki and Jarvis, Judice, & Ninke Dithering.
Fixed Bugs:
Writing certain 1 bit Sun Raster files
Reading incorrectly written PCX files
Reading 24 bit RLE compressed Sun Raster files
Reading incorrectly written ILBM files.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 32
v1.3 02/05/91
Released for Sun SPARC and IBM PC.
Added checking for supported VGA boards, warning if board is
recognized but not supported.
Fixed bug with reading and writing 8 bit Sun Raster files which
have an odd width.
Temporary files are now removed when program exits because of an
error.
Added support for reading Sun Run-Length-Encoded (RLE) files.
Added reading support for interleaved GIF files.
Added 8 bit RAW files.
Added optional smoothing on JPEG reading.
Added support for any colour component subsampling on JPEG
reading.
Targa files are now written bottom-up to make other Targa
software happy.
Added palette matching and PAL files.
Made memory use more efficient (requiring less virtual memory on
Suns and less overlay swapping on PCs).
Numerous miscellaneous performance improvements, (dramatic for
some conversions; hardly noticeable for others).
v1.2 01/16/91
First release for Sun SPARC systems.
Fixed several minor bugs (primarily aesthetic).
Made PCX file identifying and reading more robust.
v1.1 01/14/91
First release for MS-DOS.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 33
Coming Attractions
A better user's manual (yeah!).
A Macintosh Version (the Mac version is working except for the
GUI (graphical user interface].
Support for GUI (Windows 3.0 for the IBM and OpenLook 2.0 for
Suns).
Optimum Huffman table generation for JPEG writing.
Support for TIFF files containing JPEG compressed data.
Faster JPEG File reading and writing.
Emphasizing flesh tones during palette generation (for both
Uniform palettes and Heckbert generated palettes).
Gamma, Brightness, and Contrast Adjustment.
Wildcards for input filenames.
Display of images on Targa boards on IBM PCs.
Use of Expanded and/or Extended memory on IBM PCs for faster
operation.
Display of large images with scrolling (especially on PCs).
Image Resizing (scaling and/or cropping).
Binary versions for other machines (we have written what we
consider very transportable code (the same source code compiles
on IBM PCs, Macs, and Suns), the biggest limitation on generating
new binaries is access to machines, if you can provide help in
this regard please contact us).
New file formats, including:
Utah RLE
QDV
MTV
BPX
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 34
What if Image Alchemy Messes Up?
We have made every effort to insure that Image Alchemy can read
all files in its supported formats. However, because of poorly
written standards and non-adherence to standards there are
undoubtedly certain files that Image Alchemy does not read
correctly.
If you come across any files which Image Alchemy has trouble with
please contact us with as much of the following information as
you have: version of Image Alchemy you are using, type of file,
type of computer which generated it, name and version of software
which wrote the file, size of image, and the number of colours in
image. We may ask you to send us the file so that we can figure
out what went wrong. If you send us a file we will attempt to
modify Image Alchemy so that it can read the file. And if by
some miracle we manage to get it to work, we will send you an
updated copy of Image Alchemy.
Similarly, if any files that Image Alchemy writes can not be read
by other software we want to know that also. Since we do not own
a copy of every software package we may ask you to send us a copy
of a file that can be read by that package; we will then compare
that to a file written out by Image Alchemy to determine what the
problem is.
By the way, contact us even if you are not a registered user. We
figure the best way to get you to register is to be nice to you.
Trademarks
Image Alchemy is a trademark of Handmade Software, Inc.
All other products or services mentioned, including: IBM PC AT,
VGA, 8514/A, Paradise, Everex, Trident, Video 7, Tseng Labs,
Wester Digital, MS-DOS, PC-DOS, SPARC, Sun, SPARCstation,
SPARCserver, SunOS, Targa, PostScript, EPS, Encapsulated
PostScript, Gif, ILBM, IFF, Macintosh, Silicon Graphics, SGI,
PCX, TIFF, Windows, Windows BitMaP, EGA, PCL, HP, AI, PS/2, HAM,
PC Paintbrush, MacBinary, PHIPS, ColorSqueeze, VFCtool, Amiga,
CServe, and CompuServe, are trademarks, registered trademarks, or
service marks of their respective companies or organizations.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 35
Disclaimer
Handmade Software, Inc. makes no warranty of any kind, either
expressed or implied, including but not limited to implied
warranties of merchantability and fitness for a particular
purpose.
In no event shall Handmade Software, Inc. be liable for any
errors contained herein or for incidental or consequential
damages in connection with the furnishing, performance, or use of
the Image Alchemy product or documentation.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 36
Credits
Sam Leffler
Image Alchemy's TIFF I/O is based on libtiff which is
Copyright by Sam Leffler and is used with his permission.
Libtiff is available by anonymous ftp as
ucbvax.berkeley.edu:pub/tiff/*.tar.Z or
uunet.uu.net:graphics/tiff.tar.Z.
John Bridges
Image Alchemy's VGA display routines are based on VGAKIT,
originally written by John Bridges.
Marc Schneider
Who provided assistance with the Sun implementation of Image
Alchemy including Beta testing and answering questions about
the internal format of Sun Raster files.
Jack Waterman
Who proofread the manual more times than anyone should have
to read anything (any remaining misteaks are because we made
changes after he read it for the final time).
References
Floyd-Steinberg Dithering
Floyd-Steinberg, Stucki, and JJN dithering are described in
"Digital Halftoning", by Robert Ulichnet, MIT Press.
Heckbert Colour Quantization
Originally described in "Color Image Quantization for Frame
Buffer Display", SIGGRAPH '82 Proceedings, p. 297.
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 37
The following people have written image file conversion software
similar to Image Alchemy. Each of their packages is available
via anonymous ftp. These programs are only available as source
code and generally require UNIX or one of its variants.
Michael Mauldin - Fuzzy Pixmap Manipulation (FBM)
Available by anonymous ftp as
nl.cs.cmu.edu:/usr/mlm/ftp/fbm.tar.Z,
uunet.uu.net:pub/fbm.tar.Z, and ucsd.edu:graphics/fbm.tar.Z.
Jef Poskanzer - Portable BitMap (PBMPLUS)
Available by anonymous ftp as
expo.lcs.mit.edu:contrib/pbmplus.tar.Z and
ftp.ee.lbl.gov:pbmplus.tar.Z.
Jef also maintains the "Frequently Asked Questions" list in
comp.graphics, which is a great source of information on
graphics.
Paul Raveling - Img Software Set
Available by anonymous ftp as
expo.lcs.mit.edu:contrib/img_1.3.tar.Z and
venera.isi.edu:pub/img_1.3.tar.Z
Image Alchemy v1.4 Copyright (c) 1990-91 Handmade Software Inc. Page 38
Image Alchemy 1.4 Order Form
Qty Description Price Total
_____ Image Alchemy for IBM PC AT on 3.5" Disk $79.95 __________
_____ Image Alchemy for IBM PC AT on 5.25" Disk $79.95 __________
_____ Image Alchemy for Sun 4 on 3.5" Disk $79.95 __________
_____ Image Alchemy for Sun 4 on 1/4" Tape $99.95 __________
_____ Image Alchemy for Sun 3 on 1/4" Tape $99.95 __________
Sub-Total: __________
California Residents add applicable sales tax: __________
Shipping and handling ($4 UPS Ground, $8 UPS Second Day): __________
per copy ($15 FedEx, $7 International AirMail)
Total: __________
Circle Payment form: Check MC Visa Amex
Card #:______________________________________ Exp. Date: ____________
Signature: _____________________________________________________
You must include the address your credit card bill is sent to as the
billing address for MC/Visa/Amex orders.
Ship to: Bill to:
Name: ______________________________ Name: ________________________________
Company: ___________________________ Company: _____________________________
Address: ___________________________ Address: _____________________________
City: ______________________________ City: ________________________________
State: _________ Zip: __________ State: _________ Zip: ____________
Phone: (______) __________________ Fax: (______) ____________________
Mail: Handmade Software, Inc.
15951 Los Gatos Blvd., Suite 7
Los Gatos, CA 95032
Call: +1 408 358 1292
Fax: +1 408 356 4143
email: hsi@netcom.COM
email: 71330,3136 (CompuServe)